900626 Asset Configuration and Tracking Consolidation : Use Cases
This page last changed on Nov 06, 2006 by kgomes.
Create New Device in Instru
Use Case Name Create New Device in Instru
Related Requirements OSG Operator can create a new device in the Instrument database (BOG)
Goal In Context An OSG operator needs to be able to enter a new device in the insrument Microsoft Access application
Preconditions Device does not already exist in the data store
Successful End Condition New device entry is inserted and information shows up in both Access app and SSDS
Failed End Condition The device does not show up in either application
Primary Actors OSG Operator
Secondary Actors
Trigger New Device will be put in use
Included Cases
Base Use Cases
Main Flow
  1. OSG Operator opens Access Application
  2. OSG Operator clicks on button to insert new device
  3. OSG Operator fills out fields to describe new device
  4. OSG Operator clicks button to create new device
  5. A notification is sent to the OSG Operator and SSDS Administrator of device creation
Extensions
  1. After OSG Operator clicks on button to create new device, validation fails and creation is rejected
Edit Device in Instru
Use Case Name Edit Device in Instru
Related Requirements OSG Operator can update device information in Instrument Database (BOG)
Goal In Context The OSG Operators need to be able to change the information about a device in the Instrument Database Access application
Preconditions Device needs to exist in the data store where the Access application reads from
Successful End Condition Device information is updated in the data store and changes show up in SSDS and Access app
Failed End Condition No device information was updated
Primary Actors OSG Operator
Secondary Actors
Trigger
Included Cases
Base Use Cases OSG Operator finds incorrect or out of date device information
Main Flow
  1. OSG Operator opens Access Application
  2. OSG Operator searches for device
  3. OSG Operator changes form fields
  4. OSG Operator clicks button to udpate device
  5. Device information is updated in the data store
  6. Notification of change is sent to SSDS Admin describing device information update
Extensions
  1. After OSG Operator clicks on update button, information validation fails and no update takes place
Create New Device in SSDS
Use Case Name Create New Device in SSDS
Related Requirements SSDS Operator shall be able to create a new device in SSDS.
Goal In Context The system needs to have the capability for users (with appropriate permissions) add new devices to the data store.
Preconditions
  1. Device not already stored in the data store
  2. SSDS Operator has appropriate permissions to create new device
Successful End Condition New device is entered in the data store
Failed End Condition No new device is entered in the data store
Primary Actors SSDS Operator
Secondary Actors OSG Operator
Trigger A new Device needs to be put into service.
Included Cases
  1. Authenticate User
  2. Authorize User
Base Use Cases
Main Flow
  1. SSDS Operator logs into SSDS web application
  2. SSDS Operator selects link to create new device
  3. include::Authenticate User
  4. include::Authorize User
  5. SSDS Operator fills out the appropriate information
  6. SSDS Operator clicks on Submit to attempt to create new device
  7. Fields are validated
  8. Information entered is checked against data store:
    • If no UUID was entered, create one automatically
    • Make sure serial number is not null
    • Make sure manufacturer name, model and serial number do not already exist
  9. New device is entered in data store.
  10. SSDS Operator, SSDS Admin and OSG Operator are notified of new device creation.
  11. In notification to OSG Operator, he/she is presentd option of importing to Instrument Database
  12. OSG Operator clicks on link to approve transfer to Access application
  13. Data is transferred to Access data store
Extensions
  1. If field validations fail, user is presented with another try
  2. If information entered violates rule, user is presented with another try
Edit Device in SSDS
Use Case Name Edit Device in SSDS
Related Requirements SSDS Operator or Software Agent shall have interface to edit device information in SSDS.
Goal In Context Both human and software processes need interfaces to update device information in SSDS.
Preconditions Device already exist in data store
Successful End Condition Device information is updated in the data store
Failed End Condition No device information is updated in the data store
Primary Actors
    • SSDS Operator
    • Software Agent
Secondary Actors
Trigger Information about a device has changed or is incorrect
Included Cases
  1. Authenticate User
  2. Authorize User
Base Use Cases
Main Flow
    1. SSDS Operator logs into SSDS web application
    2. SSDS Operator searches for existing device
    3. SSDS Operator selects link to edit device
    4. include::Authenticate User
    5. include::Authorize User
    6. SSDS Operator changes the appropriate information
    7. SSDS Operator clicks on Submit to attempt to update device
    8. Fields are validated
    9. Information entered is checked against data store:
      • Make sure UUID is valid if changed.
      • If manufacturer information is changed, make sure it does not match up with another device already in the system.
    10. Device information is changed in the data store.
    11. SSDS Operator and SSDS Admin are notified of change in device information.
    12. If device present in Instrument Database store, OSG Operator is notified of changes in SSDS and has option of approving or editing SSDS changes, if editing takes place, OSG Operator becomes SSDS Operator and starts Main Flow again. If changes are approved, edits are propogated to the Instrument Database.
    1. Software Agent sends calls Device update service with device information.
    2. Fields are validated
    3. Information entered is checked against data store:
      • Make sure UUID is valid if changed.
      • If manufacturer information is changed, make sure it does not match up with another device already in the system.
    4. Device information is changed in the data store.
    5. SSDS Operator and SSDS Admin are notified of change in device information.
    6. If device present in Instrument Database store, OSG Operator is notified of changes in SSDS and has option of approving or editing SSDS changes, if editing takes place, OSG Operator becomes SSDS Operator and starts Main Flow again. If changes are approved, edits are propogated to the Instrument Database.
Extensions
    1. If field validations fail, user is presented with another try
    2. If information entered violates rules, user is presented with another try
    1. If field validations fail, service throws exception back to Software Agent
    2. If information entered violates rules, service throws exception back to Software Agent.
Authenticate User
Use Case Name Authenticate User
Related Requirements
Goal In Context
Preconditions
Successful End Condition
Failed End Condition
Primary Actors
Secondary Actors
Trigger
Included Cases
Base Use Cases
Main Flow
Extensions
Authorize User
Use Case Name Authorize User
Related Requirements
Goal In Context
Preconditions
Successful End Condition
Failed End Condition
Primary Actors
Secondary Actors
Trigger
Included Cases
Base Use Cases
Main Flow
Extensions
Document generated by Confluence on Feb 03, 2026 14:21